Due to the proliferation of computer software and services, an increasing trend in the computer industry has been to store software on a network and reduce the amount of software and data stored locally on a computer. This approach provides a consumer with access to a wide variety of software and also to the most recent versions of software without having to load the software from disks to each computer whenever an upgrade becomes available.
Some computers systems maintain only a minimum software configuration locally and download their remaining software from a server, including the end user operating system (OS) from a network. Otherwise known as a "network bootable device", such a system may be either a stand alone device, such as a computer terminal, or may be part of a larger device or system. Regardless of their specific implementation, network bootable devices generally share the common characteristic of a minimal software startup configuration which is supplemented by additional software provided by a server over a network or other communications link.
On-site post-production testing of network bootable devices has achieved great importance in the ensurance of product quality and reliability. Manufacturers expend a great amount of effort and expense on post-production testing prior to shipping to ensure that their products perform all of their intended functions without errors. The most robust post-production tests are "full production tests" which perform exhaustive checks of all product features. Some full production tests are performed by test application software downloaded to the device after the OS has been downloaded and is running. However, some device errors and failures can prevent the OS itself from running which precludes the use of test application software. Therefore, low level test software, in the form of a test OS, is often used. Several different approaches to low level post-production testing of network bootable devices at the manufacturing facility have been used in the past.
One approach for implementing low level production tests for network bootable devices involves temporarily installing a test ROM in the device, the test ROM already containing the code for a full production test. After startup, the full production test code provides a full production test on the device to be performed. After successful completion of the full production test, the temporary test ROM is replaced by the manufacturer with the end user ROM containing the standard startup code. This approach provides the benefit of a full production test while not occupying any space in the end user ROM. However, it is not without its disadvantages. First, the installation and removal of a test ROM increases production test costs over simply testing the end user configuration. Also, the use of a test ROM necessarily means that the tested configuration is different than the actual end user configuration. Whenever the test configuration differs from the actual end user configuration, the validity of the test is suspect. The most reliable type of production testing will test the device in its actual end user configuration. In addition, the prior approach does not allow field testing of the device, without first removing the end user ROM and temporarily installing a test ROM, which cannot be done by an end user.
As an alternative to actually installing a test ROM in the product, a "ROMulator" or ROM test jig may be used to "inject" production test code into the memory of the device so that a full production test may be performed. This approach eliminates the need to install a test ROM and therefore minimizes the likelihood that the device will be damaged or altered. However, a ROMulator or ROM test jig is usually very expensive and only allows the testing of one device per test jig. Moreover, the use of a ROMulator or ROM test jig has nearly the same testing uncertainty as a test ROM and still does not allow for field testing of the device.
Another approach for implementing low level production tests for network bootable devices involves embedding the production test code in non-volatile memory, typically in "OS ROMs". The test code resides concurrently with the OS and may be executed when necessary. This approach provides a full production test of the end user device configuration without the added costs associated with using a test ROM or ROMulator. Moreover, this approach allows the device to be field tested without changing the hardware configuration. However, this approach has several disadvantages. First, a full production test occupies valuable ROM space which instead could be used for the OS. Since the full production test code is not part of the operational software, and in most cases is only used once, the test code becomes "dead code" and the space occupied by the dead code in ROM becomes wasted space. In addition, once programmed into the device's ROM, the test code cannot be easily updated. Although flash ROMs may provide the capability to update the embedded test code, such an update is not easily performed in all cases.
As a compromise to a full production test, many network bootable devices include only a minimal production test embedded in the OS ROM. Although the OS ROM can be difficult to change, this approach provides a reasonably good test without using large amounts of ROM space, but still fails to provide a full production test.